For point-to-multipoint (PtM) services (also denoted as one-to-many services) over systems such as the Internet Protocol (IP) multicast, the IP Data Casting (IPDC) and the Multimedia Broadcast/Multicast Services (MBMS), file delivery such as for instance the download of multimedia files is an important service.
However, many of the features for delivering files over point-to-point (PtP) protocols, such as for instance the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP), are problematic for PtM scenarios. In particular, the reliable delivery of files, i.e. the guaranteed delivery of files, using similar PtP acknowledgement (ACK) protocols such as the Transmission Control Protocol (TCP) is not feasible.
The Reliable Multicast Transport (RMT) Working Group of the International Engineering Task Force (IETF) is currently in the process of standardizing two categories of error-resilient multicast transport protocols. In the first category, reliability is implemented through the use of (proactive) Forward Error Correction (FEC), i.e. by sending a certain amount of redundant data that can help a receiver in reconstructing erroneous data; in the second category, reliability is implemented through the use of receiver feedback, i.e. by the receiver sending acknowledgments (ACKs) or non-acknowledgements (NACKs) concerning received data.
Asynchronous Layered Coding (ALC) is a protocol instantiation belonging to the first category, while the NACK-Oriented Reliable Multicast (NORM) protocol belongs to the second category. The access networks on which these protocols could be used include, but are not limited to, wireless multiple-access networks such as the Universal Mobile Telecommunications System (UMTS, including the Global System for Mobile Communications Evolution Radio Access Network (GERAN) and the UMTS Terrestrial Radio Access Network (UTRAN)), Wireless Local Area Networks (WLAN), Digital Video Broadcasting—Terrestrial (DVB-T) networks and Digital Video Broadcasting—Satellite (DVB-S) networks.
NACK messages are not generally NORM-specific, but they can also be used in connection with other protocols or systems, for instance with systems that support sessions that are controlled by the File Delivery over Unidirectional Transport (FLUTE) protocol.
FLUTE is a one-to-many transport protocol that builds on FEC and ALC building blocks. It is intended for file delivery from transmitter(s) to receiver(s) over unidirectional systems. It has specializations which make it suitable to wireless PtM systems. The details of the FLUTE protocol are discussed in more detail in the publication entitled “FLUTE—File Delivery over Unidirectional Transport” (Internet Draft) prepared by the above-mentioned RMT Working Group of the IETF.
The use of FLUTE is for instance specified by the Third Generation Partnership Project (3GPP) for file download in sessions of the MBMS system. FEC may or may not have been used in such FLUTE sessions. In any case, not all receivers in the session can be expected to receive the whole file when the session ends. To this end, 3GPP is in the process of defining PtP repair sessions, wherein the receivers are allowed to signal requests for transmissions of repair data symbols, for instance data symbols that were not received correctly by a receiver, to a transmitter or repair server via NACK messages in order to receive enough data symbols and then to be able to reconstruct the downloaded content. In said NACK messages, said repair data symbols required by said receivers have to be sufficiently identified, so that the repair server is able to determine which data symbols have to be transmitted or re-transmitted.
When a receiver is scheduled for a repair session, a PtP session, for instance an HTTP session, is then established between the receiver and the repair server, in which the required repair data symbols are transmitted to the receiver.
Although the data symbols are transmitted in a PtM session, which is based on an unreliable protocol, as for instance the User Datagram Protocol (UDP), and the repair data symbols are transmitted in a PtP session, which is based on a reliable protocol, as for instance the Transmission Control Protocol (TCP), repair data symbols are currently furnished with the same header information as the data symbols. This header information comprises:                a default Layered Coding Transport (LCT) header,        an LCT Header Extensions section, and        an FEC Payload ID section.        
The LCT header comprises:                a first section with an array of flags, an LCT header length field and a Code Point field for signalling the FEC Encoding ID,        a Congestion Control Information (CCI),        a Transport Session Identifier (TSI),        a Transport Object Identifier (TOI),        a Sender Current Time (SCT), and        an Expected Residual Time (ERT).        
However, repair data symbols should be sent in the most efficient way such that the receiver can easily identify the repair data symbols and finish decoding the file(s) that were partially downloaded during the multicast/broadcast PtM session. The overhead incurred in the transmission of repair data symbols, which usually represents a re-transmission of already sent data symbols, should thus be kept small to reduce the PtP response time while keeping the receiver operations simple.